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JAVA VIRTUAL MACHINE HARDWARE FOR SUMMARY OF THE INVENTION 

RISC AND CISC PROCESSORS ^ presem inveQtion generally relates l0 a Java hardware 

BACKGROUND OF THE INVENTION accelerator which can be used to quickly translate Java 

, TM - ,. t . . , . . - bytecodes into native instructions for a central processing 

Java™ is an object orientated programming language s ' /pmA _ . , , 4 . y . 6 

developed by Sun Microsystems. Tht Java language is umt .< CPlJ >- V*****™' accelerator speeds up the pro- 

small, simple and portable across platforms and operating cessln 8 ° f the Java bytecodes significantly because it 

u *u * *u a f *u u ■ 1 i r™ . removes the bottleneck which previously occurred when the 

systems, both at the source and at the binary level. This T . lka . " r ' . " TT A 

' ! 4 u t -i i iL Java Virtual Machine is run in software on the CPU to 

makes the Java programming language very popular on the A , . T . 4 , . „ A . . 4 

Internet r °" » » © j r r ^ translate Java bytecodes into native instructions. 

Java's platform independence and code compaction are k^e ?™™\ mventi ° n > ^ P art °* ^ ^va Virtual 
the most significant advantages of Java over conventional Machlne , 15 ^P^ented in hardware as the Java hardware 
programming languages. In conventional programming accelerator. The Java hardware accelerator and the CPU can 
languages, the source code of a program is sent to a compiler be £ u ' '°S | ;ther , on a sm 8 le semiconductor chip to provide an 
which translates the program into machine code orprocessor M embedded system appropriate for use with commercial 
instructions. The processor instructions are native to the fiances, ^ch an embedded system solution is less 
system's processor. If the code is compiled on an Intel-based pensive than a powerful superscalar CPU and has a 
system, the resulting program will only run on other Intel- rebtivel y low P ower °°™™P'™- 
based systems. If it is desired to run the program on another Th* hardware Java accelerator can convert the stack- 
system, the user must go back to the original source code, 20 based Java bytecodes into a register-based native instruc- 
obtain a compiler for the new processor, and recompile the tions on a CPU. The hardware accelerators of the present 
program into the machine code specific to that other pro- invention are not limited for use with Java language and can 
cessor. be used with any stack-based language that is to be con- 
Java operates differently. The Java compiler takes a Java verted to reg^r-based native instructions. Also, the present 
program and, instead of generating machine code for a 25 invention can be used with any language that uses 
particular processor, generates bytecodes. Bytecodes are mstrucUons, such as bytecodes, which run on a virtual 
instructions that look like machine code, but aren't specific macnine. 

to any Pressor. To execute a Java program, a bytecode BRIEF DESCRIPTION OF THE DRAWINGS 
interpreter takes the Java bytecode converts them to equiva- 
lent native processor instructions and executes the Java 30 The present invention may be further understood from the 
program. The Java byte code interpreter is one component of following description in conjunction with the drawings, 
the Java Virtual Machine. FIG< i & a diagram of the system of the present invention 

Having the Java programs in bytecode form means that including the hardware Java accelerator, 

instead of being specific to any one system, the programs 35 FIG 2 is a diagram illustrating the use of the hardware 

can run on any platform and any operating system as long a Java accelerator of the present invention. 

Java Virtual Machine is available. This allows a binary rTr ~ . .„ . 4 . , A c T 

i_ * j ci . i_ < L1 , iC J FIG. 3 is a diagram illustrating some the details of a Java 

bytecode file to be executable across platforms. . , c , c ^ 

. . hardware accelerator of one embodiment of the present 

The disadvantage of using bytecodes is execution speed. invention 

System specific programs that run directly on the hardware An A . ,. .« A 4 . o , ,. 

from which they are compiled, run significantly faster that FI , G ' f 4 15 a dw 8 pun ^^ratmg the details of one embodi- 

Java bytecodes, which must be processed by the Java Virtual m< f ° f * Java aCC f f rator t . inmon translation in the 

Machine. The processor must both convert the Java byte- s * stem of * e P resent * ventlon ' 

codes into native instructions in the Java Virtual Machine FIG - 5 1S a diagram illustration the instruction translation 

and execute the native instructions. 45 operation of one embodiment of the present invention. 

One way to speed up the Java Virtual Machine is by FI G - 6 is a diagram illustrating the instruction translation 

techniques such as the "Just in Time" (JIT) interpreter, and system of one embodiment of the present invention using 

even faster interpreters known as "Hot Spot JITs" interpret- instruction level parallelism. 

ers. The JIT versions all result in a JIT compile overhead to FIGS. 7A-7D is the diagram of the table showing the 

generate native processor instructions. These JIT interpret- 50 possible list of byte codes which can cause exception in the 

ers also result in additional memory overhead. preferred embodiment. 

The slow execution speed of Java and overhead of JIT 

interpreters have made it difficult for consumer appliances DETAILED DESCRIPTION OF THE 

requiring local-cost solutions with minimal memory usage PREFERRED EMBODIMENTS 

and low energy consumption to run Java programs. The 55 FIG. 1 is a diagram of the system 20 showing the use of 

performance requirements for existing processors using the a hardware Java accelerator 22 in conjunction with a central 

fastest JITs more than double to support running the Java processing unit 26. The Java hardware accelerator 22 allows 

Virtual Machine in software. The processor performance pa rt of the Java Virtual Machine to be implemented in 

requirements could be met by employing superscalar pro- hardware. This hardware implementation speeds up the 

cessor architectures or by increasing the processor clock 60 processing of the Java byte codes. In particular, in a pre- 

frequency. In both cases, the power requirements are dra- ferred embodiment, the translation of the Java bytecodes 

matically increased. The memory bloat that results from JIT into native processor instructions is at least partially done in 

techniques, also goes against the consumer application the hardware Java accelerator 22. This translation has been 

requirements of low cost and low power. part of a bottleneck in the Java Virtual Machine when 

It is desired to have an improved system for implementing 65 implemented in software. In FIG. 1, instructions from the 

Java programs that provides a low-cost solution for running instruction cache 24 or other memory is supplied to the 

Java programs for consumer appliances. hardware Java accelerator 22. If these instruction are Java 
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bytecode, the hardware Java accelerator 22 can convert these 
bytecodes into native processor instruction which are sup- 
plied through the multiplexer 28 to the CPU. If a non-Java 
code is used, the hardware accelerator can be by-passed 
using the multiplexer 26. 

The Java hardware accelerator can do, some or all of the 
following tasks: 

1. Java bytecode decode; 

2. identifying and encoding instruction level parallelism 
(ILP), wherever possible; 

3. translating bytecodes to native instructions; 

4. managing the Java stack on a register file associated 
with the CPU or as a separate stack; 

5. generating exceptions on instructions on predetermined 
Java byte codes; 

6. switching to native CPU operation when native CPU 
code is provided; 

7. performing bounds checking on array instructions; and 

8. managing the variables on the register file associated 
with the CPU. 

In a preferred embodiment, the Java Virtual Machine 
functions of bytecode interpreter, Java register, and Java 
stack are implemented in the hardware Java accelerator. The 
garbage collection heap and constant pool area can be 
maintained in normal memory and accessed through normal 
memory referencing. 

The major advantages of the Java hardware accelerator is 
to increase the speed in which the Java Virtual Machine 
operates, and allow existing native language legacy 
applications, software base, and development tools to be 
used. A dedicated microprocessor in which the Java byte- 
codes were the native instructions would not have accesss to 
those legacy applications. 

Although the Java hardware accelerator is shown in FIG. 
1 as separate from the central processing unit, the Java 
hardware accelerator can be incorporated into a central 
processing unit. In that case, the central processing unit has 
a Java hardware accelerator subunit to translate Java byte- 
code into the native instructions operated on by the main 
portion of the CPU. 

FIG. 2 is a state machine diagram that shows the operation 
of one embodiment of the present invention. Block 32 is the 
power-on state. During power-on, the multiplexer 28 is set 
to bypass the Java hardware accelerator. In block 34, the 
native instruction boot-up sequence is run. Block 36 shows 
the system in the native mode executing native instructions 
and by-passing the Java hardware accelerator. 

In block 38, the system switches to the Java hardware 
accelerator mode. In the Java hardware accelerator mode, 
Java bytecode is transferred to the Java hardware accelerator 
22, converted into native instructions then sent to the CPU 
for operation. 

The Java accelerator mode can produce exceptions at 
certain Java bytecodes. These bytecodes are not processed 
by the hardware accelerator 22 but are processed in the CPU 
26. As shown in block 40, the system operates in the native 
mode but the Java Virtual Machine is implemented in the 
CPU which does the bytecode translation and handles the 
exception created in the Java accelerator mode. 

The longer and more complicated bytecodes that are 
difficult to handle in hardware can be selected to produce the 
exceptions. FIG. 7 is a table showing one possible list of 
bytecodes which can cause exceptions in a preferred 
embodiment. 

FIG. 3 is a diagram illustrating details of one embodiment 
of the Java hardware accelerator of the present invention. 
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The Java hardware accelerator includes Java accelerator 
instruction translation hardware 42. The instruction transla- 
tion Unit 42 is used to convert Java bytecodes to native 
instructions. One embodiment of the Java accelerator 
instruction translation hardware 42 is described in more 
detail below with respect to FIG. 4. This instruction trans- 
lation hardware 42 uses data stored in hardware Java reg- 
isters 44. The hardware Java Registers store the Java Reg- 
isters defined in the Java Virtual Machine. The Java 
Registers contain the state of the Java Virtual Machine, 
affect its operation, and are updated after each bytecode is 
executed. The Java registers in the Java virtual machine 
include the PC, the program counter indicating what byte- 
code is being executed; Optop, a pointer to the top of the 
operand stack; Frame, a pointer to the execution environ- 
ment of the current method; and Vars, a pointer to the first 
local variable available of the currently executing method. 
The virtual machine defines these registers to be a single 
32-bit word wide. The Java registers are also stored in the 
Java stack which can be implemented as the hardware Java 
stack 50 or the Java stack can be stored into the CPU 
associated register file. 

In a preferred embodiment, the hardware Java registers 44 
can include additional registers for the use of the instruction 
translation hardware 42. These registers can include a reg- 
ister indicating a switch to native instructions and a register 
indicating the version number of the system. 

The Java PC can be used to obtain bytecode instructions 
from the instruction cache 24. In one embodiment the Java 
PC is multiplexed with the normal program counter 54 of the 
central processing unit 26 in multiplexer 52. The normal PC 
54 is not used during the operation of the Java hardware 
bytecode translation. In another embodiment, the normal 
program counter 54 is used as the Java program counter. 

The Java registers are a part of the Java Virtual Machine 
and should not be confused with the general registers 46 or 
48 which are operated upon by the central processing unit 
26. In one embodiment, the system uses the traditional CPU 
register file 46 as well as a Java CPU register file 48. When 
native code is being operated upon the multiplexer 56 
connects the conventional register file 46 to the execution 
logic 26c of the CPU 26. When the Java hardware accel- 
erator is active, the Java CPU register file 48 substitutes for 
the conventional CPU register file 46. In another 
embodiment, the conventional CPU register file 46 is used. 

As described below with respect to FIGS. 3 and 4, the 
Java CPU register file 48, or in an alternate embodiment the 
conventional CPU register file 46, can be used to store 
portions of the operand stack and some of the variables. In 
this way, the native register-based instructions from the Java 
accelerator instruction translator 42 can operate upon the 
operand stack and variable values stored in the Java CPU 
register file 48, or the values stored in the conventional CPU 
register file 46. Data can be written in and out of the Java 
CPU register file 48 from the data cache or other memory 58 
through the overflow/underflow line 60 connected to the 
memory arbiter 62. The overflow/underflow transfer of data 
to and from the memory to can done concurrently with the 
CPU operation. Alternately, the overflow/underflow transfer 
can be done explicitly while the CPU is not operating. The 
overflow/underflow bus 60 can be implemented as a tri-state 
bus or as two separate buses to read data in and write data 
out of the register file when the Java stack overflows or 
underflows. 

The register files for the CPU could alternately be imple- 
mented as a single register file with native instructions used 
to manipulate the loading of operand stack and variable 
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values to and from memory. Alternately, multiple Java CPU 
register files could be used: one register file for variable 
values, another register file for the operand stack values, and 
another register file for the Java frame stack holding the 
method environment information. 

The Java accelerator controller (co-processing unit) 64 
can be used to control the hardware Java accelerator, read in 
and out from the hardware Java registers 44 and Java stack 
50, and flush the Java accelerator instruction translation 
pipeline upon a "branch taken" signal from the CPU execute 
logic 26c. 

The CPU 26 is divided into pipeline stages including the 
instruction fetch 26a, instruction decode 26b, execute logic 
26c, memory access logic 26d, and writeback logic 26e. The 
execute logic 26c executes the native instructions and thus 
can determine whether a branch instruction is taken and 
issue the ''branch taken" signal. 

FIG. 4 illustrates an embodiment of a Java accelerator 
instruction translator which can be used "with the present 
invention. The instruction buffer 70 stores the bytecode 
instructions from the instruction cache. The bytecodes are 
sent to a parallel decode unit 72 which decodes multiple 
bytecodes at the same time. Multiple bytecodes are pro- 
cessed concurrently in order to allow for instruction level 
parallelism. That is, multiple bytecodes may be converted 
into a lesser number of native instructions. 

The decoded bytecodes are sent to a state machine unit 74 
and Arithmetic Logic Unit (ALU) 76. The ALU 76 is 
provided to rearrange the bytecode instructions to make 
them easier to be operated on by the state machine 74. The 
state machine 74 converts the bytecodes into native instruc- 
tions using the look-up table 78. Thus, the state machine 74 
provides an address which indicates the location of the 
desired native instruction in the look-up table 78 . Counters 
are maintained to keep a count of how many entries have 
been placed on the operand stack, as well as to keep track of 
the top of the operand stack. In a preferred embodiment, the 
output of the look-up table 78 is augmented with indications 
of the registers to be operated on at line 80. The register 
indications are from the counters and interpreted from 
bytecodes. Alternately, these register indications can be sent 
directly to the Java CPU register file 48 shown in FIG. 3. 

The state machine 74 has access to the Java registers in 44 
as well as an indication of the arrangement of the stack and 
variables in the Java CPU register file 48 or in the conven- 
tional CPU register file 46. The buffer 82 supplies the 
translated native instructions to the CPU. 

The operation of the Java hardware accelerator of one 
embodiment of the present invention is illustrated in FIGS. 
5 and 6. FIG. 5, section 1 shows the instruction translation 
of the Java bytecode. The Java bytecode corresponding to 
the mnemonic iadd is interpreted by the Java virtual machine 
as an integer operation taking the top two values of the 
operand stack, adding them together and pushing the result 
on top of the operand stack. The Java translating machine 
translates the Java bytecode into a native instruction such as 
the instruction ADD Rl, R2. This is an instruction native to 
the CPU indicating the adding of value in register Rl to the 
value in register R2 and the storing of this result in register 
R2. Rl and R2 are the top two entries in the operand stack. 

As shown in FIG. 5, section II, the Java register includes 
a PC value of "Value A" that is incremented to "Value A+l". 
The Optop value changes from "Value B" to "Value B-l" to 
indicate that the top of the operand stack is at a new location. 
The Vars value which points to the top of the variable list is 
not modified. In FIG. 5, section III, the contents of a Java 
CPU register file, such as the Java CPU register file 48 in 
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FIG. 3, is shown. The Java CPU register file starts off with 
registers R0-R5 containing operand stack values and regis- 
ters R6-R7 containing variable values. Before the operation 
of the native instruction, register Rl contains the top value 

5 of the operand stack. Register R6 contains the first variable. 
After the execution of the native instruction, register R2 now 
contains the top value of the operand stack. Register Rl no 
longer contains a valid operand stack value and is available 
to be overwritten by a operand stack value from the memory 

10 sent across the overflow/underflow line 60 or from the 
bytecode stream. 

FIG. 5, section IV shows the memory locations of the 
operand stack and variables which can be stored in the data 
cache 58 or in main memory. For convenience, the memory 

15 is illustrated without illustrating any virtual memory 
scheme. Before the native instruction executes, the address 
of the top of the operand stack, Optop, is "Value B". After 
the native instruction executes, the address of the top of the 
operand stack is "Value B-l" cbntainirig the result of the 

20 native instruction. Note that the operand stack value "4427" 
can be written into register Rl across the overflow/ 
underflow line 60. Upon a switch back to the native mode, 
the data in the Java CPU register file 48 should be written to 
the data memory. 

25 Consistency must be maintained between the Hardware 
Java Registers 44, the Java CPU register file 48 and the data 
memory. The CPU 26 and Java Accelerator Instruction 
Translation Unit 42 are pipelined and any changes to the 
hardware java registers 44 and changes to the control 

30 information for the Java CPU register file 48 must be able to 
be undone upon a "branch taken" signal. The system pref- 
erably uses buffers (not shown) to ensure this consistency. 
Additionally, the Java instruction translation must be done 
so as to avoid pipeline hazards in the instruction translation 

35 unit and CPU. 

FIG. 6 is a diagram illustrating the operation of instruction 
level parallelism with the present invention. In FIG. 6 the 
Java bytecodes iload^n and iadd are converted by the Java 
bytecode translator to the single native instruction ADD R6, 

40 Rl. In the Java Virtual Machine, iload__n pushes the top 
local variable indicated by the by the Java register VAR onto 
the operand stack. 

In the present invention the Java hardware translator can 
combine the iload_n and iadd bytecode into a single native 

45 instruction. As shown in FIG. 6, section II, the Java Register, 
PC, is updated from "Value A" to "Value A+2". The Optop 
value remains "value B". The value Var remains at "value 
C\ 

As shown in FIG. 6, section III, after the native instruction 

50 ADD R6, Rl executes the value of the first local variable 
stored in register R6, "1221", is added to the value of the top 
of the operand stack contained in register Rl and the result 
stored in register Rl. In FIG. 6, section IV, the Optop value 
does not change but the value in the top of the register 

55 contains the result of the ADD instruction, 1371. 

The Java hardware accelerator of the present invention is 
particularly well suited to a embedded solution in which the 
hardware accelerator is positioned on the same chip as the 
existing CPU design. This allows the prior existing software 

60 base and development tools for legacy applications to be 
used. In addition, the architecture of the present embodiment 
is scalable to fit a variety of applications ranging from smart 
cards to desktop solutions. This scalability is implemented in 
the Java accelerator instruction translation unit of FIG. 4. 

65 For example, the lookup table 78 and state machine 74 can 
be modified for a variety of different CPU architectures. 
These CPU architectures include reduced instruction set 
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computer (RISC) architectures as well as complex instruc- 12. The system of claim 1, wherein the stack-based 

tion set computer (CISC) architectures. The present inven- instructions are Java bytecode, 

tion can also be used with superscalar CPUs or very long 13, The system of claim 1, wherein the hardware unit 

instruction word (VUW) computers. implements at least part of a Java virtual machine. 

While the present invention has been described with 5 14. The system of claim 1, wherein the hardware unit is 

reference to the above embodiments, this description of the connected between a memory and the central processing 

preferred embodiments and methods is not meant to be unit. 

construed in a limiting sense. For example, the term Java in 15. The system of claim 14, wherein the hardware unit is 

the specification or claims should be construed to cover connected between an instruction cache and the central 

successor programming languages or other programming JQ processing unit. 

languages using basic Java concepts (the use of generic 16. The system of claim 1, wherein the hardware unit is 

instructions, such as bytecodes, to indicate the operation of adapted to manage a Java stack. 

a virtual machine). It should also be understood that all 17. The system of claim 1, wherein the hardware unit has 

aspects of the present invention are not to be limited to the access to at least one bus of the central processing unit, 

specific descriptions, or to configurations set forth herein. 18. The system of claim 1, wherein the hardware unit is 

Some modifications in form and detail the various embodi- 35 adapted to examine the stack-based instructions to determine 

ments of the disclosed invention, as well as other variations whether multiple stack-based instructions can be combined 

in the present invention, will be apparent to a person skilled into fewer register-based instructions, 

in the art upon reference to the present disclosure. It is 19. The system of claim 18, wherein the hardware unit 

therefore contemplated that the following claims will cover produces register-based instructions that access the portion 

any such modifications or variations of the described 20 of the operand stack in the register file so as to reduce the 

embodiment as falling within the true spirit and scope of the number of register-based instructions that would otherwise 

present invention. be required. 

We claim: 20. The system of claim 18, wherein multiple stack-based 

1. A system comprising: instructions pass through the hardware unit concurrently to 
a central processing unit having a register file, the central 25 allow for the operation of the combining logic. 

processing unit adapted to execute register-based 21. The system of claim 1, wherein the hardware unit is 

instructions; and adapted to convert multiple Java bytecodes into a single 

a hardware unit associated with the central processing register-based instruction, 

unit, the hardware unit adapted to convert stack-based 22. The system of claim 21, wherein the multiple Java 

instructions into register-based instructions, wherein a 30 bytecodes include a basic operand instruction and one or 

portion of the operand stack is stored in the register file more stack manipulation instructions, 

of the central processing unit and wherein the hardware 23. The system of claim 21, wherein the multiple Java 

unit is adapted to produce at least one of overflow or bytecodes includes a load or store instruction, 

underflow indications for the portion of the operand 24. The system of claim 1, wherein the central processing 

stack stored in the register file, wherein the hardware 35 unit and hardware unit are on the same chip, 

unit is adapted to swap parts of the operand stack in and 25. The system of claim 1, wherein the hardware unit 

out of the register file from a memory, the system produces an exception upon at least one of the stack-based 

including an indication of the depth of the portion of instructions, and wherein the central processing unit will, in 

operand stack, wherein a overflow or underflow pro- software, translate the at least one of the stack-based instruc- 

duces an operand transfer between the register file in 40 tions causing the exception. 

the central processing unit and memory. 26. The system of claim 1, wherein the hardware unit 

2. The system of claim 1, wherein the central processing includes logic to keep a count of how many entries have 
unit includes the hardware unit. been placed on the operand stack. 

3. The system of claim 1, wherein the hardware unit is 27. The system of claim 1, wherein the hardware unit 
outside of the central processing unit. 45 includes logic that keeps track of portions of the Java 

4. The system of claim 1, wherein the system includes an operand stack stored in the register file and when a Java 
indication of the depth of the portion of operand stack stored bytecode to be translated references an element of the Java 
in the register file. operand stack stored in a register of the register file, the 

5. The system of claim 1, wherein, the stack based hardware unit produces an indication of that register to be 
instructions are Java bytecodes. 50 used in the translation process. 

6. The system of claim 1, wherein the registers of the 28. The system of claim 1, wherein the hardware unit 
register file of the central processing unit used to store the keeps track of a top of stack register location, wherein the 
portion of operand stack is full of valid data. top of stack register in the register file is not fixed and can 

7. The system of claim 6, wherein the at least one of the change as a result of an executed instruction. 

overflow or underflow indications is generated by a stack 55 29. The system of claim 1, wherein the hardware subunit 

instruction pushing an operand or popping the operand from keeps track of which registers in the register file contain 

the operand stack. portions of the Java operand stack, the meaning of the 

8. The system of claim 1, wherein the hardware unit has registers being able to change as a result of an executed 
access to the date bus of the central processing unit. instruction. 

9. The system of claim 1, wherein the hardware unit is 60 30. The system of claim 2, wherein the central processing 
further adapted to store at least some Java variables in the unit includes an execution unit to execute the register-based 
register file. instructions. 

10. The system of claim 1, wherein the hardware unit is 31. The system of claim 1, wherein the translated register- 
further adapted to store at least some Java registers in the based instructions are produced internally within the central 
register file. 65 processing unit. 

11. The system of claim 1, wherein the stack-based 32. The system of claim 1, wherein register-based instruc- 
instructions are associated with a virtual machine. tions cause the manipulation of the register file. 
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33. A system comprising: 42. The central processing unit of claim 39, wherein the 
a central processing unit having a register file, the central hardware subunit is further adapted to store at least some 

processing unit adapted to execute register-based Java variables in the register file. 

instructions; and 43. The central processing unit of claim 39, wherein the 

a hardware unit associated with the central processing 5 hardware subunit is further adapted to store at least some 

unit, the hardware unit adapted to convert Java byte- Java registers in the register file. 

code instructions into register-based instructions, 44. The central processmg unit of claim 39, wherein the 

wherein the hardware unit is adapted to store at least central processing unit includes an indication of the depth of 

one Java variable in the central processing unit's reg- me portion of operand stack stored in the register file, 

ister file at a location separate from any operand stack, 10 45 * ^ central processing unit of claim 39 wherein the 

wherein at least one of the register-based instructions indication of the operand stack depth is stored in the 

reference a register in the central processing unit's hardware subunit. 

register file containing one of the at least one Java 46 ^ central processing unit of claim 39 wherein a 

variable, wherein a portion of the operand stack is overflow or underflow produces operand transfer between 

stored in the register file of the central processing unit 15 me register file in the central processing unit and memory, 

and wherein the hardware unit is adapted to produce at 47 - ^ <x ni ™ 1 processing unit of claim 39 wherein, the 

least one of overflow or underflow indications for the stack-based instructions are Java bytecodes. 

portion of the operand stack stored in the register file. 48 * ^ <* ntXdX processing unit of claim 37, wherein the 

34. The system of claim 33, wherein the central process- registers of the register file of the central processing unit 
ing unit includes the hardware unit. 20 used to store me portion of operand stack is full of valid data. 

35. The system of claim 33, wherein the hardware unit is 49 - ^ <* nt ™ 1 processing unit of claim 37, wherein the 
outside of the central processing unit. at least one of &e overflow or underflow indications is 

36. A system comprising: generated by a stack instruction pushing an operand or 
a central processing unit having a register file, the central °**™L ^ TT^ ^ , • ,u 

processing unit adapted to execute register-based 25 ™ e f ntr ^ Pressing unit of claim 37 wherein the 

* * j* j stack-based instructions are associated with a virtual 

instructions; and machine 

a hardware unit associated with the central processing "51. ^ e central processing unit of claim 50, wherein the 

unit, the hardware unit adapted to convert Java byte- stack ^ ased instructions are ^ a Java virtua i 

code instructions into register-based instructions, 30 mac h me 

wherein the hardware unit is adapted to store at least J2 ^ ocessi uni t of claim 37 wherein lhe 

one Java register in the central processing unit s reg- stack+ased are Java bytecodes. 

ister file, wherein at least one of the register-based 53 ^ processing unit of claim 37 wherein , he 

mstructions reference a register m the central process- hardwar6 subuflit . lements at least t of a Java virtual 

uig unit s register file containing one of the at least one 3J macn j ne 

Java register, the at least one Java register mcluding the g4 ^ centfal ocessin unit of cUim 37 wherein , he 

Java program counter wherein a portion of the operand hardware subunit fa ^ ted tQ ffl a Jaya ^ 

stack is stored in Uie register file of the central pro- 55 ^ central ocessi unit of * lajnj 37 wherein , he 

cessmg unit and wherein the hardware unit is adapted hardware subunit nas access tQ at ^ Qne bus of ^ central 

to produce at least one of overflow or underflow 4Q Drocess j n o unit 

indications for the portion of the operand stack stored 5fi ^ processing unit of claim 39> wherein , he 

C ? Ster 7 1 • , hardware subunit is adapted to examine the stack-based 

37. The system of claim 36, wherem the central process- instructions t0 determine whether mu]tiple stack . based 

«g ""hides the hardware unit. . . instructions can be combined into fewer register-based 

38. The system of claim 36, wherem the hardware unit is 45 instructions 

outside of the central processing unit. 5? ^ ^ processin unit of claim 56> wherein the 

39. A central processing unit comprising: hardware subunit produces register-based instructions that 
an input adapted to receive stack-based instructions; access the portion of the operand stack in the register file so 
a register file adapted to be manipulated using register- as to reduce the number of register-based instructions that 

based instructions, the register file adapted to store a 50 would otherwise be required. 

portion of an operand stack; and 58. The central processing unit of claim 56, wherein 

a hardware subunit adapted to convert stack-based multiple stack-based instructions pass through the hardware 

instructions into register-based instructions, wherein subunit concurrently to allow for the operation of the 

the hardware subunit is adapted to produce at least one combining logic. 

of overflow or underflow indications for the portion of 55 59. The central processing unit of claim 39, wherein the 
the operand stack stored in the register file, wherein the hardware subunit is adapted to convert multiple Java byte- 
hardware subunit is adapted to swap parts of the codes into a single register-based instruction, 
operand stack in and out of the register file from a 60. The central processing unit of claim 59, wherein the 
memory, the system including an indication of the multiple Java bytecodes include a basic operand instruction 
depth of the portion of operand stack, wherein a over- 60 and one or more stack manipulation instructions, 
flow or underflow produces an operand transfer 61. The central processing unit of claim 59, wherein the 
between the register file and memory. multiple Java bytecodes includes a load or store instruction. 

40. The Central Processing Unit of claim 39, wherein, the 62. The central processing unit of claim 39, wherein the 
stack-based instructions are Java bytecodes. hardware subunit produces an exception upon at least one of 

41. The central processing unit of claim 39, wherein the 65 the stack-based instructions, and wherein the central pro- 
hardware subunit is adapted to swap parts of the operand cessing unit will, in software, translate the at least one of the 
stack in and out of the register file from a memory. stack-based instructions causing the exception. 
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63. The system of claim 39, wherein the hardware subunit 
includes logic to keep a count of how many entries have 
been placed on the operand stack. 

64. The system of claim 39, wherein the hardware subunit 
includes logic that keeps track of Java variables stored in the s 
register file and when a Java bytecode to be translated 
references a Java variable stored in a register of the register 
file, the hardware subunit produces an indication of that 
register to be used in the translation process. 

65. The system of claim 39, wherein the hardware subunit 10 
includes logic that keeps track of portions of the Java 
operand stack stored in the register file and when a Java 
bytecode to be translated references an element of the Java 
operand stack stored in a register of the register file, the 
hardware unit produces an indication of that register to be 15 
used in the translation process. 

66. The system of claim 39, wherein the hardware subunit 
keeps track of which registers in the register file contain 
portions of the Java operand stack, the meaning of the 
registers being able to change as a result of an executed 20 
instruction. 

67. The system of claim 39, wherein the central process- 
ing unit includes an execution unit to execute the register- 
based instructions. 

68. The system of claim 39, wherein the translated 25 
register-based instructions are produced internally within the 
central processing unit. 

69. A central processing unit comprising: 

an input adapted to receive Java bytecode instructions; 

a register file adapted to be manipulated using register- 30 

based instructions, the register file adapted to store a 

portion of an operand stack; aod 
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a hardware subunit adapted to convert Java instructions 
into register-based instructions, wherein the hardware 
subunit is adapted to store at least one Java variable in 
the register file at a location separate from any operand 
stack, wherein at least one of the register-based instruc- 
tions reference a register in the central processing unit's 
register file containing one of the at least one Java 
variable, wherein the hardware subunit is adapted to 
produce at least one of overflow or underflow indica- 
tions for the portion of the operand stack stored in the 
register file. 
70. A central processing unit comprising: 
an input adapted to receive Java bytecode instructions; 
a register file adapted to be manipulated using register- 
based instructions, the register file adapted to store a 
portion of an operand stack; and 
a hardware subunit adapted to convert Java instructions 
into register-based instructions, wherein the hardware 
subunit is adapted to store at least one Java register in 
the register file, wherein at least one of the register- 
based instructions reference a register in the central 
processing unit's register file containing one of the at 
least one Java register, the at least one Java Register 
including the Java Program Counter, wherein the hard- 
ware subunit is adapted to produce at least one of 
overflow or underflow indications for the portion of the 
operand stack stored in the register file. 
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